Method for reliable and efficient filesystem metadata conversion

ABSTRACT

A method for converting metadata in a hierarchical configuration within a filesystem from a first format to a second format includes reading metadata that is in the first format within the hierarchical configuration; writing the metadata from the hierarchical configuration into a flat file; and writing the metadata back into the hierarchical configuration, the metadata being in the second format. The method can also include increasing the size of each of a first inode and a second inode within a first inode chunk in the filesystem, assigning the first inode to the first inode chunk, and assigning the second inode to a second inode chunk. Additionally, the method can also include (i) writing a plurality of directory extents from a first location within the filesystem to a second location, each directory extent identifying a location and a length of a contiguous range of directory blocks, and (ii) generating an arranged directory extent list so that the contiguous ranges of directory blocks are listed in substantially the same order as the directory extents were listed at the first location within the filesystem. The method can further include writing the arranged directory extent list from the hierarchical configuration into the flat file. The method can further comprise writing the arranged directory extent list from the flat file back into the hierarchical configuration.

BACKGROUND

Metadata can generally be referred to as data that describes other data.More specifically, filesystem metadata may include descriptiveinformation about the context, quality, condition, and characteristicsof data within a filesystem. A filesystem typically includes a hierarchyof directories (or a directory tree) that is used to organize files on acomputer. For example, within some filesystems, an item of metadata maydescribe an individual data point or content item, or an item ofmetadata may describe a file or collection of data, wherein the file orcollection of data may include a hierarchical structure which definesthe relationship between different data points within the file. Inparticular, metadata may include information such as the name or title,size, length, ownership, location, etc. for any data point or collectionof data.

Within many filesystems, the metadata that describes the various filesand/or directories in the filesystem is stored in a data structure or aseries of data structures called inodes. Each inode, which is assigned aunique inode number within that filesystem, is designed to store up to acertain amount of information or metadata about the file. Further, an“inode chunk” is a collection of a certain number of inodes storedcontiguously on disk. Additionally, the size of the inodes is typicallyset when the filesystem is created.

Over time, new features may be implemented in the filesystem software.These features may require changes or additions to the metadatacontained in the filesystem's inodes. Eventually, as more additions orchanges are made, there may be no space left in the inode to supportdesired new functionality. Therefore, in such situations, there is aneed to convert metadata contained in the inodes from the existingformat to another format.

Previous attempts to convert metadata have resulted in the process beingunreasonably time consuming, thereby causing excessive downtime of thefilesystem, or, more importantly, an inadequate uptime of thefilesystem. Additionally, the integrity of the metadata may be at riskdue to the possibility of failure during the conversion process.

When converting a filesystem with hundreds of gigabytes of metadata,efficiency and reliability are of the upmost importance. Filesystems cancontain hundreds of millions of inodes consuming hundreds of gigabytesof disk space. Metadata storage can typically perform at most a fewhundred input/output (I/O) operations per second, so the time to rapidlyconvert a large filesystem can become unreasonable. Since metadataobjects tend to be relatively small and generally not contiguous ondisk, an efficient scheme for converting metadata cannot rely on readingitems one by one from disk and chasing associating structures.

Another aspect of efficiency is the amount of storage required. Theconversion process should not require disproportionate amounts of newstorage nor render existing storage unusable due to fragmentation.

Clearly, reliability in any metadata conversion process is alsoimportant. A filesystem with hundreds of millions of files has greatvalue to the user. Large filesystems take longer to convert, and thegreater the conversion time, the greater the risk for failure during theconversion process. Accordingly, any viable scheme for convertingmetadata must allow for recovery from any failures, for example, processand/or node failures, during the conversion.

SUMMARY

The present invention is directed to a method for converting metadata ina hierarchical configuration within a filesystem from a first format toa second format. In certain embodiments, the method comprises the stepsof: reading metadata that is in the first format within the hierarchicalconfiguration; writing the metadata from the hierarchical configurationinto a flat file; and writing the metadata back into the hierarchicalconfiguration, the metadata being in the second format.

In one embodiment, the method further comprises the steps of scanningthe metadata to compile a list of inode chunks and sorting the list ofinode chunks based on their location within the filesystem.

Additionally, in some embodiments, the method further comprises thesteps of increasing the size of each of a first inode and a second inodewithin a first inode chunk in the filesystem, assigning the first inodeto the first inode chunk, and assigning the second inode to a secondinode chunk. In one such embodiment, the first inode includes anoriginal first inode number and the second inode includes an originalsecond inode number. Moreover, in one embodiment, the method furthercomprises the steps of retaining the original first inode number for thefirst inode and assigning a new second inode number for the secondinode.

Further, in one embodiment, the method further comprises the step ofwriting the first inode chunk and the second inode chunk from thehierarchical configuration to the flat file. In such embodiment, themethod further comprises the step of writing the first inode chunk andthe second inode chunk from the flat file back into the hierarchicalconfiguration.

In some embodiments, the method further comprises the steps of (i)writing a plurality of directory extents from a first location withinthe filesystem to a second location, each directory extent identifying alocation and a length of a contiguous range of directory blocks, and(ii) generating an arranged directory extent list so that the contiguousranges of directory blocks are listed in substantially the same order asthe directory extents were listed at the first location within thefilesystem. In one such embodiment, the method further comprises thestep of writing the arranged directory extent list from the hierarchicalconfiguration into the flat file. Moreover, in such embodiment, themethod further comprises the step of writing the arranged directoryextent list from the flat file back into the hierarchical configuration.

Additionally, the present invention is further directed to a filesystemcomprising a file and metadata that describes the file. In oneembodiment, the filesystem is adapted to convert the metadata from afirst format to a second format utilizing the method as described above.

BRIEF DESCRIPTION OF THE DRAWINGS

The novel features of this invention, as well as the invention itself,both as to its structure and its operation, will be best understood fromthe accompanying drawings, taken in conjunction with the accompanyingdescription, in which similar reference characters refer to similarparts, and in which:

FIG. 1 is a simplified flow chart illustrating one embodiment of amethod for converting metadata of a filesystem from a first format to asecond format according to the present invention;

FIG. 2A is a simplified schematic diagram of one embodiment of ahierarchical configuration within a filesystem that utilizes themetadata conversion method illustrated in FIG. 1;

FIG. 2B is a simplified schematic diagram of one embodiment of a flatfile that is generated to store metadata from the filesystem illustratedin FIG. 2A; and

FIG. 3 is a simplified schematic diagram of one embodiment of aplurality of unconverted inode chunks in an unconverted filesystem and aplurality of converted inode chunks in a converted filesystem thatutilized a method disclosed herein.

DESCRIPTION

As an overview, the present invention describes a method for convertingmetadata of a filesystem from a first format to a second format. Oneexample of such a conversion can include increasing the capacity of eachof the storage blocks, e.g., inodes, of the metadata. The methodsdisclosed herein can provide substantially improved efficiency in theamount of time required to fully convert the metadata from the firstformat (original capacity) to the second format (increased capacity)and/or in the amount of storage space required to complete the metadataconversion. Additionally or alternatively, the methods disclosed hereincan provide substantially improved reliability, so that there can be amuch greater likelihood that the metadata does not get lost, damaged, orotherwise compromised during the conversion process.

The methods described in detail herein can be utilized with similarsuccess for a variety of different filesystems. In one non-exclusiveexample, one or more of the methods provided herein can be used with ahierarchical configuration within a filesystem that scales to hundredsof millions of files, hundreds of gigabytes of metadata, and petabytesof user data. However, the methods described herein are equallyapplicable to other types and sizes of filesystems.

FIG. 1 is a simplified flow chart illustrating one embodiment of amethod for converting metadata of a filesystem from a first format to asecond format utilizing the teachings as described in the presentinvention. As utilized herein, metadata can include several differentforms of data. For example, in one embodiment, metadata can include oneor more inodes, one or more directory extents, one or more superblocks,one or more allocation bitmaps, etc. In alternative embodiments,metadata can include additional forms and/or can be found in differentlocations within the filesystem.

Additionally, in the embodiment described herein, the filesystemincludes a plurality of inodes that are allocated in contiguous 512 KBinode chunks. In this embodiment, each inode can have an initial storagecapacity of 512 bytes and each inode chunk initially contains 1,024inodes. Each inode can be associated with one or more levels within thefilesystem. For example, in a hierarchical configuration within afilesystem, inodes can be associated with one or more directories, oneor more subdirectories, one or more files, etc. In alternativeembodiments, the filesystem can include inodes that have an initialstorage capacity of greater than or less than 512 bytes, can includeinode chunks that have a storage capacity of greater than or less than512 KB, and/or can include inode chunks that initially encompass greaterthan or less than 1024 inodes. It is recognized that the foregoingembodiment is provided as one representative example for ease ofunderstanding, and is not intended to limit the scope of the inventionin any manner.

Further, within the filesystem, each inode includes an inode number thatis embedded in various locations throughout the metadata. The inodenumber can encode the physical location of the inode on disk. Asutilized herein, disk is the storage medium being utilized for storingthe contents of the filesystem, although other types of storage mediafor storing the contents of the filesystem can be equally be used,including tape, virtual tape, optical disk, etc. In some embodiments,the inode number includes both the number of the inode chunk (which canbe numbered “1” through however many inode chunks are present within thefilesystem), and the number of the inode within that inode chunk (whichwould typically be numbered as “1” through “1024” for the unconvertedfilesystem where there are 1,024 inodes within each inode chunk). By wayof example, in one embodiment, if a particular inode was inode number237 within inode chunk 1, then the full inode number would be 1,0237. Inanother example, if a particular inode was inode number 749 within inodechunk 6, then the full inode number would be 6,0749. It should be notedthat the method for generating the inode numbers for the inodes issimply an example of how the inode numbers can be generated, and is notmeant to be limiting in any way, as other numbering methods arepossible.

FIG. 1 provides one method for converting metadata from a filesystemfrom the first format to the second format. It is recognized that innonexclusive alternative embodiments, the method can include additionalsteps other than those specifically delineated herein or can omitcertain of the steps that are specifically delineated herein. Moreover,in some embodiments, the order of the steps described below can bemodified without deviating from the spirit of the present invention.

Initially, in step 100, operation of the filesystem can be stopped and avirtual snapshot of metadata that is in the first format within thefilesystem, i.e., the metadata which has not yet been converted from thefirst format to the second format, is taken. In one embodiment, thisvirtual snapshot is taken at the volume level. The virtual snapshotenables the user to identify and isolate the full volume of metadatathat is present within the filesystem at any given time. In thisembodiment, the filesystem initially appears as including a hierarchicalconfiguration within the filesystem that defines the relationships ofdata and metadata within a hierarchy of directories, subdirectories,files, etc., as explained in greater detail relative to FIG. 2.Additionally, as noted above, the metadata can include one or moreinodes, one or more directory extents, one or more superblocks, one ormore allocation bitmaps, etc.

In step 102, the allocation bitmaps that are present on disk are readfrom the disk and then written into a flat file format, or a dumpdirectory (i.e., a directory where the flat file is maintained). Duringthis step, the filesystem uses a feature that is designed to constructone or more “flat files” (also sometimes referred to herein as a“metadump”) in a local filesystem that will ultimately be utilized tocontain all of the allocation bitmaps, the inodes, the directoryextents, the superblocks and/or any other type of metadata. In certainembodiments, the flat file can be a part of the filesystem that containsthe metadata that is in the first format. In alternative embodiments,the flat file can be separate and distinct from the filesystem thatcontains the metadata that is in the first format.

As utilized herein, a flat file is essentially a long list of objectsthat represents the metadata that is contained in the filesystem. Theobjects encapsulate all of the internal structure and relationshipspresent in the filesystem. The flat file can be read start to finish andthe data contained therein used to restore the metadata to its originalstate in the event of a disaster. Alternatively, only a portion of themetadata can be contained within the flat file.

For example, the flat file format can provide certain advantages insituations when the filesystem, such as a RAID system in onenon-exclusive embodiment, that contains all the metadata fails or isphysically destroyed or otherwise prevents access to the metadata. Inalternative embodiments wherein the original filesystem does not includeor illustrate the various hierarchical relationships between the dataand metadata, step 102 can be omitted.

In step 104, a list of inode chunks is constructed and sorted by disklocation. For example, in one embodiment, the metadata is scanned tobuild or compile a list of inode chunks, which are then sorted based ontheir physical location on disk. As provided above, each inode chunkinitially contains a predetermined number of inodes, such as 1,024. Incertain embodiments, the inode chunks are linked from one inode chunk tothe next. In such embodiments, a single block from each inode chunk canbe read to successfully identify the physical location of the inodechunk and the location of the next inode chunk. The single block that isread from within the inode chunk typically encompasses one or moreinodes within the inode chunk. Stated another way, this step involvesreading just enough information from each inode chunk so that thephysical location of the inode chunk can be identified. Further, becausethe inode chunks are linked sequentially, the location of the next inodechunk can be determined. Moreover, the location of the inode chunks canbe identified regardless of where within the inode chunk the block thatis being read is positioned.

In step 106, space is pre-allocated for new inode chunks. Adetermination is made as to whether there is sufficient previouslyunused space in the filesystem to contain the converted, i.e.,reformatted, inodes. If it is determined that sufficient unused space isavailable in the filesystem, the necessary space is pre-allocated forthe reformatted inodes. As noted above, in this embodiment, the inodesin the filesystem are allocated in contiguous 512 KB chunks, eachcontaining 1,024 inodes of 512 bytes each. To maintain the requiredorganization of the metadata during the metadata conversion process, thestorage capacity of each inode must be increased. In the embodimentdescribed herein, each inode is expanded to hold 1,024 bytes ofinformation instead of the previous 512 bytes of information. If thenumber of inodes per chunk is increased, the size of each inode chunkmust be increased. If the inode chunk size remains the same, the numberof inodes per chunk must be reduced. Because inode chunks are frequentlynot allocated right next to one another on disk, if the inode chunk sizewere increased from 512 KB to 1,024 KB, fragmentation would prevent thespace allocated to the existing inode chunks from being reused.Therefore, in certain embodiments, for greater efficiency of space usageand to avoid unwanted fragmentation, the inode chunk size is kept at 512KB and the number of inodes per chunk is reduced to 512.

Accordingly, during the conversion process, the size or storage capacityof each inode chunk remains at 512 KB, but the inodes are increased totwice the size, so that each inode can store twice the previous amountof metadata. For example, in one embodiment, each inode can now store1,024 bytes of information instead of the previous 512 bytes. Therefore,in this embodiment, with the chunk size remaining the same, and with theinode capacity for each individual inode doubling in size, each inodechunk now contains only 512 inodes instead of the previous 1,024. Inalternative embodiments, the metadata conversion process can be designedwherein the inode chunk size is increased to 1,024 KB so that the inodechunk can now contain 1,024 of the inodes with increased storagecapacity.

Still alternatively, in certain embodiments, during the conversionprocess, the size of the inodes can be increased by other than a factorof two. For example, in some embodiments, the size of the inodes can beincreased so that three times or four times or some other multiple ofthe previous amount of metadata can be stored in each inode. Statedanother way, in an embodiment wherein the size of the inodes isincreased by a factor of three, each inode would be able to store threetimes the amount of information of the original inode, e.g., 1,536 bytesof information when each inode previously held 512 bytes of information.Somewhat similarly, in an embodiment wherein the size of the inodes isincreased by a factor of four, each inode would be able to store fourtimes the amount of information of the original inode, e.g., 2,048 bytesof information when each inode previously held 512 bytes of information.

During step 106, for each inode chunk, the allocation bitmaps are usedto find a contiguous 512 KB chunk of metadata space. Moreover, becausethe size of each inode has increased to 1,024 bytes from the previous512 bytes without the overall inode chunk size increasing, a firstsubset of the inodes in the original inode chunk can remain in theoriginal inode chunk. Further, a second subset of the inodes in theoriginal inode chunk will move to a new predetermined inode chunk. Moreparticularly, in certain embodiments, the first subset of the inodes andthe second subset of the inodes can include approximately the samenumber of inodes. In one such embodiment, the first subset of inodes andthe second subset of inodes can include exactly the same number ofinodes. Stated another way, during the conversion process, one half ofthe inodes in the original inode chunk are assigned back to the originalinode chunk, and a second half of the inodes in the original inode chunkare assigned to the new predetermined inode chunk. Pre-allocating thenew inode chunks allows for building of a global mapping system from oldinode numbers to new inode numbers and determines whether there isenough previously unused space to complete the conversion.

In alternative embodiments, when the size of the inodes is increased byother than a factor of two, during the conversion process, one subset ofinodes in the original inode chunk would be assigned back to theoriginal inode chunk, and additional subsets of inodes would be assignedto new predetermined inode chunks. Stated another way, a newpredetermined inode chunk would be used for each factor that the size ofeach of the inodes is increased. For example, in an alternativeembodiment wherein the size of each inode is increased by a factor ofthree, during the conversion process, one third of the inodes in theoriginal inode chunk would be assigned back to the original inode chunk,one third of the inodes in the original inode chunk would be assigned toa second predetermined inode chunk, and one third of the inodes in theoriginal inode chunk would be assigned to a third predetermined inodechunk. Somewhat similarly, in an embodiment wherein the size of eachinode is increased by a factor of four, during the conversion process,one fourth of the inodes in the original inode chunk would be assignedback to the original inode chunk, one fourth of the inodes in theoriginal inode chunk would be assigned to a second predetermined inodechunk, one fourth of the inodes in the original inode chunk would beassigned to a third predetermined inode chunk, and one fourth of theinodes in the original inode chunk would be assigned to a fourthpredetermined inode chunk.

In step 108, a global mapping system is constructed from the physicallocation of the old inode chunk to the physical location of the newinode chunk. As noted above, within the filesystem, each inode includesan inode number that is embedded in various locations throughout themetadata. The inode number encodes the physical location of the inode ondisk. The global mapping system, as provided herein, tracks how toconvert inode numbers in the previous, unconverted filesystem to inodenumbers in the new, converted filesystem. In certain embodiments, theglobal mapping system can allow inode numbers to be converted withoutchasing or tracking on disk structures. Further, the global mappingsystem can allow reading, converting and writing to the metadump file ina single pass. As such, substantial time can be saved during thisportion of the process by obviating additional passes through thefilesystem.

In this embodiment, because each inode chunk now contains only one-halfof the original number of inodes, the inode numbers must also beadjusted. In one embodiment, one-half of the inodes in the originalinode chunk will remain in the original inode chunk, and the second halfof the inodes in the original inode chunk will move to a new inodechunk. By way of example, an original inode chunk can include inodenumbers of 1,0001 through 1,1024, where the first “1” represents thechunk number and the remaining four digits represent the specific inodewithin the chunk from “1” to “1024”. When the size of each inode ischanged (i.e., doubled in size), the inode chunk now only has spaceavailable for 512 inodes. Therefore, based on space availability,previous inodes 1,0001 through 1,0512 will still include the same inodenumber and will still be contained in the same inode chunk (e.g., inodenumber 1,0005 will remain in inode chunk “1” as inode number 1,0005).However, as sufficient space is no longer available within the old inodechunks, previous inodes 1,0513 through 1,1024 will now require a newinode number and will now be contained in a new inode chunk. If the newchunk is, for example, inode chunk “14”, the inodes that were previouslynumbered in inode chunk “1” as 1,0513 through 1,1024 will now benumbered as 14,0001 through 14,0512, respectively. It is recognized thatthe foregoing numbering convention is one representative example, andother number conventions could alternatively be utilized.

For example, in one embodiment, once an inode is moved from the previousinode chunk to the new inode chunk, to determine the new inode numberwithin that new inode chunk, 512 is subtracted from the previous inodenumber within the previous inode chunk. So, if the previous inode numberwas 1,0748, and this inode is being moved to new inode chunk “14”, thenthe new inode number for this inode will be 14,0236, as 748 minus 512equals 236. In another example, if the previous inode was in inode chunk“6” and had an inode number of 6,1010, and if this inode is being movedto new inode chunk “19”, then the new inode number for this inode willbe 19,0498, as 1010 minus 512 equals 498. In alternative embodiments, adifferent specific methodology can be utilized to determine what the newinode number would or should be based on the old or previous inodenumbers, as long as the methodology provides a consistent manner for thenew inode numbers to be determined and subsequently associated with theprevious inode numbers.

In step 110, each of the inode chunks are read sequentially from disk.For each inode chunk read from disk, two 512 KB in-memory buffers arepopulated with converted inodes. In one embodiment, half of theconverted inodes will need to be moved to new inode chunks and have newinode numbers. Thus, the global mapping system, as described in step108, must be used to convert the embedded inode numbers for each of theinodes that will be moved to the new inode chunks. Accordingly, areliable and organized system has been created so that related metadatawithin the related inodes can be easily located within the convertedfilesystem. Additionally, valuable time can be saved in converting theinode numbers that are embedded at various locations throughout themetadata.

As noted above, in addition to the allocation bitmaps and the regularinodes that are included within the metadata, certain metadata withinthe filesystem includes directory extents. Directory extents can becontained within what are referred to herein as directory inodes. Aswith the regular inodes, directory inodes are also contained within theinode chunks. A directory typically includes a list of names and inodenumbers that are affiliated with the various files that are containedwithin the directory. The list of names and inode numbers is containedin directory blocks. The directory extents describe the location andlength of a contiguous range of directory blocks on disk. Stated anotherway, the directory extents provide information that includes thelocation and number of directory blocks that are included within acontiguous range of directory blocks.

In step 112, the directory extents are read from the filesystem andwritten into a directory flat file data structure (e.g., a tree) with aseparate entry being inserted into the directory flat file for eachdirectory extent. In one embodiment, the entry can include the physicallocation of the directory extent on disk. In alternative embodiments,the directory extents can be written into another suitable locationother than the directory flat file.

In step 114, the two converted inode chunks (for each original inodechunk as described above in step 110), along with some descriptiveheader information, can be written from the in-memory buffers to themetadump file.

In step 116, a sorted list of contiguous ranges of directory extents isbuilt. After all the inode chunks have been read, converted, and storedin the metadump file, the tree of directory extent information, i.e.,the information on the location and length of the contiguous range ofdirectory blocks that was generated in step 112, is iterated and theranges of directory extents are arranged into an orderly directoryextent list so that the directory extents are listed substantially inon-disk order. In one embodiment, the directory extent list includes thedirectory extents being listed precisely in on-disk order. For eachrange, this list contains a starting disk offset (i.e., a physicallocation) and a length. In this embodiment, the tree of directoryextents can include an important property of being easy and efficient toiterate the objects it contains (i.e., the contiguous ranges ofdirectory extents) in a logical order.

This metadata conversion method can improve the efficiency of certainI/O operations. The use and arranging of directory extent trees asdescribed herein helps the user in achieving this goal by making the I/Ooperations that are required to read and update all of the directoryextents vastly more efficient by making them as sequential as possible.Two ways to optimize the I/O operations to read the directory extentswithin the filesystem are (i) to conduct the I/O operations in order, asis greatly enabled by building the sorted list of contiguous ranges ofdirectory extents, and (ii) to make the I/O operations as large aspossible. For example, if the tree of directory extents described thedirectory extents in the ranges of [7,10], [11,25], [26,50], [61,67],and [68,100], the ranges can be effectively chunked together so that theranges of directory extents can be illustrated as [7,50] and [61,100].Accordingly, the tree of directory extents can be iterated by conductingtwo larger I/O operations instead of the five smaller I/O operations aswould have otherwise been required. With this design, because directoryextents tend to be rather small and somewhat randomly distributed ondisk, at least a fivefold to tenfold reduction in the extent processingtime can be achieved.

In step 118, each range of directory extents is read from disk into anin-memory buffer. This step continues by walking through the buffer onedirectory at a time from beginning to end, utilizing the sorted list ofcontiguous ranges of directory extents that was created in step 116. Ifthe directory block contains directory entries, then the processcontinues to iterate through the directory entries. The global mappingsystem is utilized to make any necessary conversion of old inode numbersto new inode numbers, as described above in relation to step 108.

In step 120, the range of directory extents with converted inode numbersis written from the in-memory buffer to the metadump file.

In step 122, any required fixups, such as updates to inode numbers inthe superblocks, are performed. At this point, the metadump file hasbeen established that contains the converted filesystem data (i.e.,converted inodes, converted directory extents, converted superblocks,etc.), as a result of only one full pass through the filesystem. Themetadump file is well organized in that the data in the metadump file issequential in substantially the same way that the data is sequential ondisk.

In step 124, the process includes iterating sequentially through theflat, metadump file and writing its data back to the hierarchicalconfiguration within the filesystem. At this point, all of the metadatais now contained within the filesystem in the newly converted secondformat. In the event that any failures occurred during step 124, such aspossible process or node failures, only step 124 would need to berestarted.

In step 126, the filesystem is restarted. If for some reason thefilesystem cannot be restarted, the volume snapshot created in step 100can be used to roll-back and restore the filesystem back to its originalstate.

FIG. 2A is a simplified schematic diagram of one embodiment of ahierarchical configuration within a filesystem 228 that can utilize themetadata conversion method as illustrated in FIG. 1. As illustrated, thefilesystem can include one or more directories (identified as D1 throughD3), one or more subdirectories (identified as SD1 through SD4), and oneor more files (identified as F1 through F7) that are organized in ahierarchical relationship relative to each other. Additionally, thefilesystem 228 can further include a volume of metadata (identified asM1 through M27) that is contained within a plurality of inodes that arein turn organized within a plurality of inode chunks. In one embodiment,the filesystem 228 is designed so that an amount of metadata isassociated with and utilized to describe the contents of each of the oneor more directories, the one or more subdirectories, and/or the one ormore files. The number of directories, subdirectories, files andmetadata illustrated in FIG. 2A is provided for ease of discussion onlyand is not intended to be limiting in any manner.

FIG. 2B is a simplified schematic diagram of one embodiment of a flatfile 230 that could be created from the filesystem 228 illustrated inFIG. 2A. As illustrated, the metadata is all organized in the same levelregardless of whether the metadata is associated with and utilized todescribe the contents of each of the one or more directories, the one ormore subdirectories, and/or the one or more files.

FIG. 3 is a simplified schematic diagram of one embodiment of aplurality of unconverted inode chunks 332A in an unconverted filesystem328A and a plurality of converted inode chunks 332B in a convertedfilesystem 328B, wherein the conversion utilizes the method as disclosedin the present invention. In this embodiment, the unconverted filesystem328A includes four unconverted inode chunks 332A (labeled as “1” through“4”), with each unconverted inode chunk including 1,024 inodes.Alternatively, the unconverted filesystem 328A can include more thanfour or less than four unconverted inode chunks 332A. Further, in thisembodiment, the converted filesystem 328B includes eight converted inodechunks 332B (labeled as “1” through “8”), with each converted inodechunk 332B including 512 inodes. Alternatively, the converted filesystem328B can include more than eight or less than eight converted inodechunks 332B.

During the conversion of the unconverted inode chunks 332A to theconverted inode chunks 332B, half of the inodes that were in the firstunconverted inode chunk are assigned to the first converted inode chunk,and half of the inodes in the first unconverted inode chunk are assignedto the fifth converted inode chunk. Somewhat similarly, half of theinodes that were in the second unconverted inode chunk are assigned tothe second converted inode chunk, and half of the inodes in the secondunconverted inode chunk are assigned to the sixth converted inode chunk.Additionally, half of the inodes that were in the third unconvertedinode chunk are assigned to the third converted inode chunk, and half ofthe inodes in the third unconverted inode chunk are assigned to theseventh converted inode chunk. Further, half of the inodes that were inthe fourth unconverted inode chunk are assigned to the fourth convertedinode chunk, and half of the inodes in the fourth unconverted inodechunk are assigned to the eighth converted inode chunk.

While a number of exemplary aspects and embodiments have been discussedabove, those of skill in the art will recognize certain modifications,permutations, additions and sub-combinations thereof. It is thereforeintended that the following appended claims and claims hereafterintroduced are interpreted to include all such modifications,permutations, additions and sub-combinations as are within their truespirit and scope.

1. A method for converting metadata in a hierarchical configurationwithin a filesystem from a first format to a second format, the methodcomprising the steps of: reading metadata that is in the first formatwithin the hierarchical configuration; writing the metadata into a flatfile; and writing the metadata back into the hierarchical configuration,the metadata being in the second format.
 2. The method of claim 1further comprising the steps of scanning the metadata to compile a listof inode chunks and sorting the list of inode chunks based on the ondisk location of the inode chunks.
 3. The method of claim 1 furthercomprising the steps of increasing the size of each of a first inode anda second inode within a first inode chunk in the filesystem, assigningthe first inode to the first inode chunk, and assigning the second inodeto a second inode chunk.
 4. The method of claim 3 wherein the firstinode includes an original first inode number and the second inodeincludes an original second inode number, and further comprising thesteps of retaining the original first inode number for the first inodeand assigning a new second inode number for the second inode.
 5. Themethod of claim 3 further comprising the step of writing the first inodechunk and the second inode chunk to the flat file.
 6. The method ofclaim 5 further comprising the step of writing the first inode chunk andthe second inode chunk from the flat file back into the hierarchicalconfiguration.
 7. The method of claim 1 further comprising the steps of(i) writing a plurality of directory extents from a first locationwithin the filesystem to a second location, each directory extentidentifying a location and a length of a contiguous range of directoryblocks, and (ii) generating an arranged directory extent list so thatthe contiguous ranges of directory blocks are listed in substantiallythe same order as the directory extents were listed at the firstlocation within the filesystem.
 8. The method of claim 7 furthercomprising the step of writing the arranged directory extent list intothe flat file.
 9. The method of claim 8 further comprising the step ofwriting the arranged directory extent list from the flat file back intothe hierarchical configuration.
 10. A filesystem comprising a file andmetadata that describes the file, the filesystem being adapted toconvert the metadata from a first format to a second format utilizingthe method of claim
 1. 11. A method for converting metadata in afilesystem from a first format to a second format, the method comprisingthe steps of: increasing the size of each of a first inode and a secondinode within a first inode chunk in the filesystem; assigning the firstinode to the first inode chunk; and assigning the second inode to asecond inode chunk.
 12. The method of claim 11 wherein the step ofincreasing includes the step of increasing the size of a plurality ofinodes within the first inode chunk, and further comprising the step ofassigning each of two or more subsets of the plurality of inodes to oneof a plurality of inode chunks.
 13. The method of claim 12 wherein anapproximately equal number of inodes are contained within each subset ofthe plurality of inodes.
 14. The method of claim 12 wherein an equalnumber of inodes are contained within each subset of the plurality ofinodes.
 15. The method of claim 11 further comprising the step ofconstructing a global mapping system that relates the physical locationof the first inode chunk to the physical location of the second inodechunk.
 16. The method of claim 15 wherein the first inode includes anoriginal first inode number and the second inode includes an originalsecond inode number, and wherein the step of constructing includesretaining the original first inode number for the first inode andassigning a new second inode number for the second inode.
 17. The methodof claim 11 wherein the filesystem includes a hierarchicalconfiguration, and further comprising the step of writing the firstinode chunk and the second inode chunk from the hierarchicalconfiguration to a flat file within the filesystem.
 18. The method ofclaim 17 further comprising the step of writing the first inode chunkand the second inode chunk from the flat file back into the hierarchicalconfiguration.
 19. The method of claim 11 wherein the filesystemincludes a hierarchical configuration, and further comprising the stepsof (i) writing a plurality of directory extents from a first locationwithin the filesystem to a second location, each directory extentidentifying a location and a length of a contiguous range of directoryblocks, and (ii) generating an arranged directory extent list so thatthe contiguous ranges of directory blocks are listed in substantiallythe same order as the directory extents were listed at the firstlocation within the filesystem.
 20. The method of claim 19 furthercomprising the step of writing the arranged directory extent list fromthe hierarchical configuration into a flat file.
 21. The method of claim20 further comprising the step of writing the arranged directory extentlist from the flat file back into the hierarchical configuration.
 22. Afilesystem comprising a file and metadata that describes the file, thefilesystem being adapted to convert the metadata from a first format toa second format utilizing the method of claim
 11. 23. A method forconverting metadata in a hierarchical configuration within a filesystemfrom a first format to a second format, the method comprising the stepsof: writing a plurality of directory extents from a first locationwithin the filesystem to a second location, each directory extentidentifying a location and a length of a contiguous range of directoryblocks; and arranging the directory extents so that the contiguousranges of directory blocks are listed in substantially the same order asthe directory extents were listed at the first location within thefilesystem.
 24. The method of claim 23 further comprising the steps of(i) reading metadata that is in the first format within the hierarchicalconfiguration, (ii) writing the metadata from the hierarchicalconfiguration into a flat file; (iii) scanning the metadata to build alist of inode chunks, and (iv) sorting the list of inode chunks based ontheir location within the filesystem.
 25. The method of claim 24 furthercomprising the steps of increasing the size of each of a first inode anda second inode within a first inode chunk in the filesystem, assigningthe first inode to the first inode chunk, and assigning the second inodeto a second inode chunk.
 26. The method of claim 25 wherein the firstinode includes an original first inode number and the second inodeincludes an original second inode number, the inode numbers being basedon the physical location of the corresponding inodes, and furthercomprising the steps of retaining the original first inode number forthe first inode and assigning a new second inode number for the secondinode.
 27. The method of claim 26 further comprising the steps ofwriting the first inode chunk and the second inode chunk from thehierarchical configuration to a flat file, and writing the first inodechunk and the second inode chunk from the flat file back into thehierarchical configuration.
 28. The method of claim 23 furthercomprising the step of writing the arranged directory extent list fromthe hierarchical configuration into a flat file.
 29. The method of claim28 further comprising the step of writing the arranged directory extentlist from the flat file back into the hierarchical configuration.
 30. Afilesystem comprising a file and metadata that describes the file, thefilesystem being adapted to convert the metadata from a first format toa second format utilizing the method of claim
 23. 31. A method forconverting metadata from a hierarchical configuration within afilesystem from a first format to a second format, the method comprisingthe steps of: reading metadata that is in the first format from a firstinode and a second inode within the filesystem; increasing the size ofeach of the first inode and the second inode within a first inode chunkin the filesystem; assigning the first inode to the first inode chunk;assigning the second inode to a second inode chunk; writing a pluralityof directory extents from a first location within the filesystem to asecond location, each directory extent identifying a location and alength of a contiguous range of directory blocks; arranging thedirectory extents so that the contiguous ranges of directory blocks arelisted in substantially the same order as the directory extents werelisted at the first location within the filesystem; writing the metadataand the directory extents from the hierarchical configuration into aflat file; and writing the metadata and the directory extents back intothe hierarchical configuration, the metadata being in the second format.